A typical software development project will involve many different source code modules and files that are being worked on by teams of software developers. In addition, the typical software development project will have a reasonably long life cycle of development, testing, release, and maintenance. In order track changes over time, version control systems have been developed to aid teams of software developers to maintain the often complex code associated with a particular development project. Version control systems of the prior art typically provide versioning only for files and modules comprising the development project.
However, it is frequently the case that during a project, team members desire the ability to refer to project tracking data as it existed at a prior time. Sometimes this is to locate information; sometimes it is to determine the state of the project as it existed at some particular point in time. Furthermore, it is often desirable to determine trends based on how state changes over time. Frequently these types of queries are not planned for when the project is created, and are often ad hoc.
When dealing with project data that is under configuration management, the problem becomes more complex. This is because configuration data needs to be tracked both as a whole, i.e. across all configurations, as well as for each configuration.
Previous systems have generally used one or more of several methods to maintain historical data related to a project. In a first method, a “transcript” is associated with each item. The transcript may include, among other things, the date and time of all changes to the item, including state changes. Frequently the state data is interspersed with textual data in the transcript. However, occasionally the state data is maintained separately.
In a second method used by some systems, the actual data fields aren't tracked, just the update action itself. For example, the fact that an update occurred on a particular date will be tracked, but not the project data fields that were updated.
In a third method, special fields are employed to track the date/time of specific state transitions. For example, one field can indicate a bug was opened, a second field will indicate when the bug was resolved, and a third when the bug was closed.
The first approach suffers in that it cannot be easily queried. The second approach is not viable as a general solution because the actual data is not tracked, just the fact that the data has changed. This makes it impossible to query the actual state of the data on a particular date. The third approach is not viable as a general solution because the number of transition fields becomes impractical and any fields without transition dates cannot be queried for historical data. As well, general historical data is not available because the transition dates record only the last, i.e. most recent transition. All information regarding previous transitions is lost.
In the case of configurations, most systems today support different configurations by “tagging” the data with the associated configuration. In this approach, various entities supported by the system can be tagged (i.e. labeled) with an alphanumeric identifier that identifies a configuration to which the entity belongs. This approach is sub-optimal as information about how similar problems in different configurations relate, or how project data migrates from one configuration to another can be lost.
Therefore, there is a need in the art for a system that maintains versions of project data in a manner that saves all of the previous state of a project, and that can be queried to produce a project's state at a particular point in time.